Revive webmcp dead features - #2

The App Hosting build died before installing a single dependency:

    Installing pnpm v12.0.0
    pnpm v12.0.0 detected (>= 11.0.0), downloading tarball.
    Error: Cannot find module '/layers/google.nodejs.pnpm/pnpm_engine/bin/dist/pnpm.mjs'

Nothing asked for pnpm 12. `packageManager` says `pnpm@10.14.0` and CI resolves
that correctly, but the buildpack does not read `packageManager` — it reads
`engines.pnpm`, treats it as a semver *range*, and installs the highest match
from the registry. Our `">=10"` therefore meant "whatever pnpm shipped most
recently", which is 12.0.0 as of today; confirmed by resolving the range against
registry.npmjs.org rather than inferring it from the log.

pnpm 12 then hits a broken branch in the buildpack itself: for >= 11 it unpacks
the standalone GitHub release, which is a self-contained binary, but still
launches it as `node <layer>/bin/dist/pnpm.mjs` — a path that exists only in the
npm package layout. So the failure was never about our dependencies, and no
local or CI run could have caught it, because both honour `packageManager`.

`engines.pnpm` is now an exact `10.14.0`, matching `packageManager` and the
lockfile it generated. This has to stay below 11 until that buildpack branch is
fixed.

Also drops BUILD availability from NODE_ENV, which would have been the next
failure. The buildpack installs with `pnpm install --prod`, and under
NODE_ENV=production that omits every devDependency — while this build is almost
entirely devDependencies: the Angular CLI, the Nest CLI, typescript. Nothing in
the build reads NODE_ENV (Angular takes `production` from angular.json); the
only reader in the repo is `EnvService.partnerOrigin`, per request, at runtime.
So RUNTIME availability loses nothing.

The `Failed to find version for package @angular/core in pnpm lockfile` warnings
above the failure are unrelated and expected: that is the `firebaseangular`
buildpack's detect step, which looks for Angular in the root importer and finds
it under `frontend:` instead. It exits 1 meaning "does not apply", which is
correct — this repo builds through the generic Node path with an explicit
buildCommand and runCommand.

Both gotchas recorded in apphosting.yaml and CLAUDE.md, since neither is
reproducible outside a real deploy.

Verified locally: `pnpm install --frozen-lockfile` clean on 10.14.0,
`pnpm run build` exit 0 through prerender and the SEO stamp.